Many businesses rely on large-scale data processing systems for storing and processing their data. Insurance companies, banks, brokerage firms, etc., rely heavily on data processing systems. Often the viability of a business depends on the reliability of access to data contained within its data processing system. As such, businesses seek reliable ways to consistently protect their data processing systems and the data contained therein from natural disasters, acts of terrorism, or computer hardware and/or software failures.
Businesses must be prepared to eliminate or minimize data loss and recover quickly with useable data after an unpredicted event such as a hardware or software failure in the data processing system. When an unexpected event occurs that causes loss of data, businesses often recreate the data using backup copies of their data made on magnetic storage tape. Restoring data from a backup tape is typically a time-consuming process that often results in a substantial loss of business opportunity. Business opportunity is lost because the data processing system cannot process new data transactions while data is being recreated from backup copies. Further, restoration from tape usually involves loss of data. For most businesses, this kind of data loss and down time is unacceptable. Mirrored data volume and virtual point-in-time (PIT) backup technologies offer better solutions for full and accurate restoration of business critical data. Mirrored data volume and virtual PIT technologies not only minimize or eliminate data loss, but also enable rapid recovery of a data processing system when compared to conventional bulk data transfer from sequential media.
FIG. 1 illustrates an exemplary data processing system 10 that employs mirrored data volume and virtual PIT backup technology. Data processing system 10 includes a host node 12 coupled to data storage systems 14–18. Data storage systems 14–18 include data memories 24–28, respectively. As will be more fully described below, data memory 24 stores a primary data volume, data memory 26 stores a virtual PIT backup copy of the primary data volume, and data memory 28 stores a mirrored copy of the data volume. Data processing system 10 shown in FIG. 1 and its description herein should not be considered prior art to the invention disclosed and/or claimed.
Host node 12 may take form in a computer system (e.g., a server computer system) that receives and processes requests to read or write data to the primary data volume stored within memory 24. In response to receiving these requests, host node 12 generates read or write-data transactions for reading or writing data to the primary data volume within data memory 24. It is noted that host node 12 is capable of accessing each of the memories 24–28 or memory internal to host node 12 for reading or writing data to the data volumes stored therein.
Each of the data memories 24–28 may include several memory devices such as arrays of magnetic or optical discs. The primary data volume maybe distributed across several memory devices of memory 24. Likewise, the virtual PIT copy of the primary data volume is distributed across several memory devices of data memory 26, and the mirrored copy of the primary data volume is distributed across several memory devices of data memory 28. Each of the data memories 24–28 may include nmax physical memory blocks into which data can be stored. More particularly, data memory 24 includes nmax memory blocks allocated by host node 12 for storing data of the primary data volume, data memory 26 includes nmax memory blocks allocated to store the virtual PIT backup copy of the primary data volume, and data memory 28 includes nmax memory blocks allocated to store the mirrored copy of the primary data volume. Corresponding memory blocks in data memories 24–28 are equal in size. Thus, memory block 1 of data memory 24 is equal in size to memory block 1 of data memories 26 and 28.
Host node 12 creates the virtual PIT backup copy of the primary data volume according to the methods described in U.S. patent application No. 10/143,059 entitled “Method and Apparatus for Creating a Virtual Data Copy,” and U.S. patent application Ser. No. 10/254,753 now U.S. Pat. No. 6,912,631, filed Sep. 25, 2002 and entitled “Method and Apparatus for Restoring a Corrupted Data Volume,” each of which is incorporated herein by reference in entirety. These references describe how host node 12 reads and writes data to the virtual PIT copies. Additionally, the above referenced applications describe how the virtual PIT backup copy can be converted to a real PIT backup copy using a background copying process executed by host node 12.
Host node 12 creates the virtual PIT backup copy of the primary data volume when host node receives or internally generates a command to create a PIT copy of the primary data volume. Initially (i.e., before any virtual PIT copy is created in data memory 26) data memory 26 contains no data. When host node 12 creates the first virtual PIT backup copy in memory 26, host node 12 creates a pair of valid/modified (VM) maps, such as maps 30 and 32 shown in FIG. 2. FIG. 2 also shows a third map 34 which will be more fully described below. VM maps 30 and 32 correspond to the primary data volume and the virtual PIT copy thereof, respectively, stored within data memories 24 and 26, respectively. Hence, VM maps 30 and 32 will be referred to as primary VM map 30 and PIT backup copy VM map 32.
Each of the VM maps 30 and 32 include nmax entries, each entry having two bits. Each entry of primary VM map 30 corresponds to a respective block of data memory 24, while each entry of the virtual PIT backup copy VM map 32 corresponds to a respective block of data memory 26. The first and second bits in each entry of VM maps 30 and 32 are designated Vn and Mn, respectively. Vn of each entry, depending on its state (i.e., logical 0 or logical 1), indicates whether block n of the associated memory contains valid data. Vn of the primary VM map 30 indicates whether a corresponding memory block n in memory 24 stores valid data. For example, when set to logical 1, V2 of VM map 30 indicates that block 2 of data memory 24 contains valid data of the primary data volume, and when set to logical 0, V2 of the VM map 30 indicates that block 2 of data memory 24 contains no valid data of the primary data volume. Vn of the PIT backup copy VM map 32 indicates whether memory block n in memory 26 stores a valid point-in-time copy of data in block n of memory 24. For example, V2 of VM map 32, when set to logical 1, indicates that block 2 of memory 26 contains a valid copy of data that existed in block 2 of memory 24 at the time the PIT backup copy was first created or at the time the PIT backup copy was last refreshed. U.S. application Ser. No. 10/326,427, now U.S. Pat. No. 6,880,053, entitled “Instant Refresh of A Data Volume” describes one method of refreshing a PIT backup copy and is incorporated herein by reference in entirety. V2 of VM map 32, when set to logical 0, indicates that block 2 of memory 26 does not contain a valid copy of data. The Vn bit of PIT backup copy VM map 32 is used to determine when data in block n of memory 24 is to be copied to block n of memory 26. More particularly, when host node 12 generates a write-data transaction for writing data to block n of memory 24, host node 12 checks the status of Vn in PIT backup copy VM map 32. If Vn is set to logical 0, then the PIT backup copy in memory 26 lacks a valid copy of data of block n in memory 24. Before data can be written to block n of memory 24 in accordance with the write-data transaction, data in block n of memory 24 must first be copied to block n of memory 26. If, on the other hand, Vn is set to logical 1, data can be written to block n of memory 24 in accordance with the write-data transaction without first copying data to block n of memory 26.
Mn in each entry of VM map 30 and PIT copy VM map 32, depending upon its state, indicates whether data within a respective block n of the corresponding memory is modified (or new) since the time the PIT backup copy was first created or last refreshed. For example, when set to logical 1, M3 of the primary VM map 30, indicates that block 3 of data memory 24 contains data which has been modified since the time the PIT backup copy was first created or last refreshed. When set to logical 0, M3 of the primary VM map of 30 indicates that data has not been modified or written to Block 3 of data memory 24 since the time the PIT backup copy was first created or refreshed.
When VM maps 30 and 32 are first created by host node 12, each entry of PIT VM map 32 is set to logical 0 thus indicating that data memory 26 contains no valid or modified data. For purposes of explanation, it is presumed that each block of data memory 24 contains valid data of the primary volume. Accordingly, VM of each entry within primary VM map 30 is initially set to logical 1. Lastly, Mn of each entry in primary VM map 30 is initially set to logical 0.
As noted above, data memory 28 stores a mirrored copy of the primary data volume. A mirrored copy is considered a real time copy of the primary data volume. Each time host node 12 writes data to the primary data volume stored in memory 24 via a write-data transaction, host node also generates a transaction to write the same data to the mirrored copy stored within memory 28. Thus, the mirrored copy, as its name implies, closely tracks the changes to the primary data volume. The mirrored copy within memory 28 provides an immediate backup data source in the event that data storage system 14 fails as a result of hardware and/or software failure. If data storage system 14 suddenly becomes unusable or inaccessible, host node 12 can service client computer system read or write requests using the mirrored volume within data memory 28.
Host node 12 is also subject to hardware and/or software failure. In other words, host node 12 may crash. When host node 12 recovers from a crash, host node 12 expects contents of the data memory 24 to be consistent with the contents of the data memory 28. Unfortunately, host node 12 may crash after a write-data transaction is completed to data memory 24, but before the mirrored copy can be updated with the same data of the write-data transaction. If this is to happen, the contents of the primary data copy stored in memory 24 will be inconsistent with the mirrored copy in memory 28 when host node 12 recovers from its crash.
Host node 12 uses the dirty region (DR) map 34 shown in FIG. 2 to safeguard against inconsistencies between memories 24 and 28 after crash recovery. DR map 34 includes nmax entries corresponding to the nmax memory blocks in data memories 24 and 28. Each entry includes one bit which, when set to logical 0 or logical 1, indicates whether respective memory blocks in data memories 24 and 28 are the subject of an in-progress write-data transaction. For example, host node 12 sets DR2 to logical 1 before host node 12 writes data to memory block 2 in data memories 24 and 28. Setting or clearing a bit in DR map 34 requires a write (i.e., an I/O operation) to memory that stores DR map 34. After the write transaction is completed to memory block 2 of data memories 24 and 28, host node 12 switches the state of DR2 back to 0 using another write operation.
If host node 12 crashes, the contents of DR map 34 is preserved. After recovering from the crash, host node 12 copies the contents of memory blocks in data memory 24 to respective memory blocks in data memory 28, or vice versa, for each respective DRn bit set to logical 1 in DR map 34. After these memory blocks are copied, host node 12 is ensured that the primary data volume of data memory 24 is consistent with the mirrored copy of data memory 28.
Host node 12 is burdened by having to generate two separate write operations to update VM map 30 and DR map 34 with each write-data transaction to the primary data volume. More particularly, with each write-data transaction, host node 12 must generate a first write operation to update VM map 30 and a second write operation to update DR map 34. Additionally, a substantial amount of time is needed to complete separate write operations to VM map 30 and DR map 34. To illustrate, FIG. 3 is a flow chart illustrating operational aspects of modifying or writing data of the primary volume within data memory 24 in accordance with a write-data transaction. More particularly, when host node 12 receives a request to write data to the primary volume from one of the computer systems, host node 12 generates a write-data transaction to write data to block n of memory 24. In step 42, host node 12 accesses VM map 32 to determine whether Vn is set to logical 1. If Vn of the VM map 32 is set to logical 0, then host computer 12, as shown in step 44, copies the contents of block n of memory 24 to the corresponding block n in memory 26. Thereafter, in step 46 host computer 12 sets Vn of the VM map 32 to logical 1. Before host computer system 12 writes or modifies data of block n of memory 24 that stores a portion of the primary volume and block n of memory 28 that stores a portion of the mirrored copy, host computer system 12 must set Mn and DRn of primary VM map 30 and DR map 34, respectively, to logical 1. It is noted that Mn and DRn are in separate tables, and thus have separate addresses within memory. Accordingly, host computer system 12 must generate separate writes or 10 functions to set Mn and DRn to logical 1. The time it takes, for example, for the read/write head (not shown) to travel across a magnetic disc to reach the appropriate sector that stores Mn of VM map 30, followed by the time it takes for the magnetic read/write to travel across the magnetic disc to reach another sector that stores DRn of the DR map 34, may be substantial. Once Mn and DRn are set to logical 1 in steps 50 and 52, host node 12 writes data to block n in memory 24 as shown in step 54 and writes data to block n of memory 28.